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SUMMERY 


This   is   the   report   of    the    productivity    enhancement    study 

of    the   FMSO   software    development    effort.       This    study    is   an 
intial  effort    to    identify    candidate    projects    for    productive 
ty    improvements.      tfe    do    not  atter.pt    a    detailed    analysis    of 
FMSO    problems.      Instead,     we  try    to    adopt    an    overview    of    the 
organization    and    its    problems    as    they    appear    tc    outsiders. 
It    is   the    opinion  of    the    authors    that   FMS3    is    well    managed 
and    that    employee   morale    is   generally    good,    but    that    the    or- 
ganization   faces    serious    challenges    in    both    the   near    term 
and   the    long    term.      Substantial    changes   will    have    to    be    made 
in    the   way   the   organization  does    business    ::    keep    F3S0    via- 
ble   in  the    future. 

The   major   recommendations    in    this   report    are: 

1.  F!15C   should   begin    work    on    a    Development    Tools    System 
that    will    support    computer   programming    worK,    documen- 
tation   an i  software   management.      This    should   be    a 
unified   system    (ail    parts    of    it   can    communicate    with 
other    parts)     but    net   necessarily   a    single    computer 
system. 

2.  The    physical    facilities   at    F3SO   are    below    the    recog- 
nized  standards   for   supporting    a   software    development 
operation    and    should  be   upgraded. 


3.      Some    areas  of    software    management    ?.5ed  tc    be   im- 
proved.      Notably,     a   better    project    planning    and 
tracking    system  needs   to    be    put   it    place.      Generally, 
FMSC's    software   management   effort    is    well   directed. 

The  points   covered   in    this   report   are: 

1.  An    overall   view   of    tno    Fi-130    sysxens    effort. 

2.  A    discussion,    of   the  type    of    productivity    enhancing 
effort    that   should    be    .nade. 

3.  A    proposal    for    the    installation    of    a   Development 
Tools    System    at  FM3C, 

4.  An  outline  of  the  facilities  improvements  that  should 
be  made  tc  improve  productivity  and  encourage  contin- 
ued   high    employee    morale. 

5.  Project    estimating    techniques   and 
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Chapter    1 
EACK  GROUND 

1.  1         INTRODUCTION   TO    FMSC 

The   Fleet    Material   Support    Office   is   an    unusual    Navy    com- 
mand.     It    handles  a    variety  of   responsibilities    for   the    Sup- 
ply   Corps,    but    most    of   its   work    is    to    function    as    a   Central 
Design   Activity    for    various   supply    and    financial    computer 
systems.     In    effect,    F55SO    is  the    information    systems    arm    of 
HA  VSUPSYSCCM.       The   major    mission    arsas    for    FttSO    are: 

1.  Central   Design    Agency    activities. 

2.  Management   of    the    Navy's    Retail    Steele    Fund. 

3.  Operations  analysis   activities. 

4.  Supply    operations    support. 

5.  International    logistics. 

The    CDA    activity    consumes    90%   of    FMSO*s   resources,    and    it    is 
the    area    that    we    will    be    concerned    with  in    this    report.      The 
major   concern    of    this   study  is   to    focus    on    ways    to    increase 
the    productivity    of    the    CCA  activity. 

The   major    functions   supported    by    the   CDA    activity    are: 
1.      Uniform   Automated    Data    Processing    Systems    (UDAPS)  . 

a)  Uniform   ADP   System    for    Inventory    Control   Points 
(UICP)  . 

b)  UADPS    Stock    Points     (UADPS-SP). 
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c)  Level    II/III  Stock   Points. 

d)  Disk   Oriented    Supply   System     (DOSS)  . 

2.  Headquarters    Financial    Systems. 

3.  Management   Information    System    for    International    Lo- 
gistics  -    MISIL. 

4.  Special    Data    Processing   Systems   Projects. 

a)  RHMSE    -   Requisition    Material   Monitoring    and    Expe- 
diting. 

b)  Trident  logistics  data. 

c)  NALCCMIS. 

d)  NATES    -   Navy   Automated    Transportation    Data    System. 

e)  NAVADS    -   Navy    Automated   Transportation    Documenta- 
tion  System  . 

f)  Hesolicitat  ion  . 

g)  SPAR. 

The    list    of    responsibilities    placed   on    ?MSO   is    impressive. 
If    it    were    a    private    organization,    it    would    be    a    major    soft- 
ware   house    or    computer   company.       With    approximately    1,360 
employees    FMSO   has   a    staff  that    is    about    230    smaller    than 
Apple   Computer.      The    employees   charged   with   the    CDA   activity 
have    to    maintain    a   library   of    computer   systems    consisting   of 
approximately    10,000    -    12,000    programs   totaling    en    the    order 
of    20   million   lines    of  code.      In    industrial   terms,    this    sys- 
tem   library   is   about    what    one    would   expect    to    find    in    a    ma- 
jor   high   technology    company  that    employed    around    200,000 
people.       This    library   has    been   in   development    for    10    to    20 
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years.      Again,    if   industrial    yardsticks    apply,    -hen    it    is    to 
be    expected   that    FMSO    has    spent    between    one    and    two    billion 
dollars    in    developing    this  code. 

1.2         GENERAL    PROBLEMS    AT    FMSO 

Seme    of    the    problems    that    beset    FMSO   would    occur    in    any 
information   systems    group    in    any    organization.      Information 
systems    activity    is    generally    a    service   area.       This   means 
that    others   in   the  organization    do    not    really   appreciate    the 
problems    involved  in    developing    software    and    have    little 
idea    about    effective    ways    of    doing    it.      They    expect    the    ser- 
vice   to    be   available    when    they   want    it   and    in    the    form    that 
they    want    it.      The   result    is    that    an    information    systems 
group    can    develop  serious    problems    in    its    relations   with    its 
upper    level   management    and   its   customers.       The    group    has 
little   control   ever    planning    or    resource    allocation    for    its 
area,    but    it    tends  to    get    blamed    for   everything   that    gees 
wrong.      In   FMSO's  case,    this    problem   is   iade    worse    by    the 
fact    that    their    superiors    are    in    Washington,    and  their    major 
customers    are   spread    ail    ever   the   globe.       The    reputation    of 
the    organization    suffers    as   a    consequence    even    when   its 
problems    are    not    of    its    own  making. 

Besides    these    general    sorts   of   information   systems    group 
problems,    there    is  another  set   of    problems    that    arises    for 
computing    groups    working    fcr    the    government    in    general   and 
for    the   Navy    in    particular.      During   the   fifties    and  sixties, 
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computers    were    generally    recognized    as    useful,    but   they    were 
very   expensive   and   difficult    tc    manage.      As  a   result,    a 
whole   set    cf    regulations    grew    up    around   the    use    and    procure- 
ment   of    computers  with  the   Brooks    Bill    being    the    item    most 
often   cited.      The  effect    has   been   to    require    lengthy    justi- 
fication   for    any    computer    procurement. 

The   ironic    thing    is  that  computers    have    gotten    much 
cheaper    since    these    regulations    were   first    put    into   effect. 
Computer    power   that    would    have   required   a    mainframe   twenty 
years   ago    can    now  be    purchased  at    K-Mart    in   the    toy   depart- 
ment.     For.  computer    systems  costing    between    310,000    and 
5100,000,    the    justification  of   the    system    is    one    of   the    most 
expensive    accessories    :n    the    machine.      There    have    been    two 
side    effects    cf    this.      The   first    is    to   make    managers    reluc- 
tant   to    procure    equipment    even   though    it    may    be    of   consider- 
able   benefit    tc   the    organization.      For    the    individual    manag- 
er,   a   procurment    effort    means    that    his    staff    is    occupied 
with    the    paperwork   required   to   purchase   a    computer   instead 
of    being    able   to   do    their    regular    jobs. 

Another    prcblem   that    affects    FKSO   is   the    Navy    attitude 
toward  shore    facilities.       There    seems    to    be   an    unwritten 
policy   in    the   Navy   that    the  first   priority    should    be    given 
to    the   fleet    while  shore    and   support    facilities    are   of    sec- 
ondary importance.      The    socialization   of    Naval   officers   also 
leads  them   to    accept    shore  facilities   that    are  less  than 
ideal.      Shipboard  life    involves    a    lot    of    crowding    and    dis- 
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comfort.       No   matter    how    bad  a    shore    facility    may   be,    it    is 
likely  to    be    mere  comfortable   and   spacious    than    a    shipboard 
facility.      Unfortunately    for    FJ1SO,    the   standard   of   compari- 
son   is   not    shipboard    software    development    facilities     (if 
there    were    such    a  thing) .      It    is    the   numerous    software    de- 
velopment   facilities    springing   up  all   around    the    Harrisburg 
area.      It    will   be   irr  esis table   for    FMSO   employees    to   compare 
their   working    conditions    with    those   available    at    places    like 
EDS    and    CACI. 

These    comments  apply    to   both    the    physical    plant    at    FHSO 
and    tc   the   computer    systems  upon    which   development   is    done. 
The    computers    for   which    ? MSO   does   development    work   must    be 
among   the    oldest    currently  operating.       This    is    a    costly 
preposition    from    many   points   of    view.      For    the    individual 
programmer,    it    is  costly    because    he    fails    behind   techno- 
logically.     Computer    personnel   are    an    unusual    breed.      Of    ail 
the    professions,    they   hold   professional    development    in    high- 
est   regard.      This  is    natural    considering    that    computer    tech- 
nology changes   rather   quickly,    and    that    any    individual    who 
falls   behind    is    likely   to    find   himself    out    of    a    job.       FMSO 
has    done    a    gocd    job    in   making    professional    development 
training    available   to    its    staff.       This    is    probably    a    major 
reason   for    the    remarkable    loyalty   to    the    organization    we    ob- 
served there. 

There    are    other  problems  in   trying   to    deal    with   older 
technologies    than   just    personnel    considerations.       Both    the 
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equipment    and    design    philosophies    for    operating    systems    have 
changed    considerably    since  FPlSO's    equipment    was    installed. 
Magnetic    tape    oriented   systems   for    data   processing    are    new    a 
thing  of    the    past.      Magnetic   tape   is    cheaper    than    disk,    but 
its    use    requires    a   great    deal    of    operator    intervention. 
There  are    too    many   chances   for   error    in   the    use    of    tape.       In 
a    disk   oriented    system,    the   process    of    calling    fixes    and 
setting    up    jots    is  done    automatically    without    human   inter- 
vention.      The    disk  system    may    be    more    costly    to   install,    but 
the    elimination    of   tape    handling    errors   makes    it    a    good    deal 
cheaper   in   the   long    run. 

The   same    is   true    of   older   operating    systems.       Such    sys- 
tems   generally   called    for    more  operator   intervention.       This 
opened   up    more    chance    of    error.       The   newer    philosophies    in 
operating    systems   oali    for   "programming   the    idiot    out    of    the 
loop"   -    that    is,    designing   the   system    so    that    it    rarely 
calls  on    humans    for    decisions.       A    final   point    in    the   opera- 
tion   of    older   systems   is    the    maintenance    problem.       As    a    sys- 
tem   ages,    the    manufacturer  of   the   system    becomes    less    inter- 
ested  in    performing    software   enhancements    and   updates.       He 
naturally    wants   to   concentrate  on    newer   products,    and    even- 
tually  the    software    on   the  older    system   becomes    obsolete. 
If    the   customer    does    not    upgrade    his   hardware,    he    gets    left 
behind  in    the   evolutionary  process   of   system    development. 
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1.3         PROBLEMS    IN   REACHING    A    SOLUTION 

The  problems   mentioned    abo7e    combine   to    make   long    term 
solutions    very   difficult    in  this    environment.      Acquisition 
of    new   computer    systems    or  the    institution    of    long    range 
changes    can   take    years   in    the    Navy    environment.       An    example 
of    this    is   the   ICP  Resoli citation   project.       mis    nas    been 
underway    for    about   eight    years   now,    and    the    first    machine 
should   come   on   line    in    1984    (if    all    goes    well).      This    is    an 
unconscionably    long    time    for   a    systems   change.      In    an    indus- 
trial  enviroment,   this   should    take    no    more    than    a    year    with 
only    a   few    months  spent    on   the  study   portion. 

A    critic   of   FMSO    might    argue    that    this    only    proves    that 
the    machines    were   unecessary    in    the    first    place    and   that    the 
government    has   saved    itself  eight    years    of    computer   expense 
by    staying    with    the    old    equipment.      This    is    all    quite    true. 
The    machines   are   "unnecessary"   in   the    sense    that    there    is 
always   another    way  to    do    a   oonputer    job.       In    this    C3.sa,    the 
computer    savings    were   generated    at    the    expense    of    personnel 
costs,    project   delays    and    degraded    service    for    the    naval 
supply   system. 

Unfortunately,   the   personnel    costs    do    not    get   charged    off 
to    specific   information    processing    systems   in   quite   the   same 
way    as   a    computer.      If   they  don't   appear    on    anybody's    bottom 
line,    then    there    is    a   tendency   to    regard    these    costs    as    not 
being  real. 
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The  Univac    495's    that    NV/SU?    uses   to   manage    the    ICP's 
were    obsolescent    whan  the    system    was  installed  In    1955.       By 
now,    they    are    hopelessly    out    of    date.       What    -his    means    is 
that    because   of    the    Navy's  "can    do"    attitude,    these   machines 
have    been    kept    going    long    past   their    useful    life.      The    price 
for    this    is    mere    operations  personnel,    time    spent    on    systems 
development    and   changes    to  the   operating    system,    and    time 
spent   fine    tuning   FMSO's    applications    to    get    the   most    possi- 
ble   "bang    per    buck"    out    of   a    Univac    494.       There    is    little 
doubt   that    ICP's    Univac    494's    have    been   tuned    so    -hat    they 
are    operating    more   efficiently    (where    efficiency    is   measured 
in    computer    time    only)    than  any    Univac   494's    in    history. 
Why   anyone    would    want    to    do  such    a   thing    is   another  ques- 
tion. 

1 . 4         CONCIPSICNS 

The  Commanding  Officer    cf    FMSO    faces   several    significant 
challenges.      The    organization    has   some    rsal   long   range    prob- 
lems.     These    include    systems    upgrades,    improvements   that 
need   to    be    made   to   take    advantages   of    new    technologies    and 
improvement   of   the   physical  environment.       The   steps   we    re- 
commend   to    solve    some    of    these    problems   are    going    to    gener- 
ate   short    range   chaos.      A    CO's   tour   of   duty   is    only  two 
years.      If   a   new   CO    came    in  and    accepted    all    of    our   recom- 
mendations   on    the   first    day  of  his    tour,    then    by    the    end    of 
his    tour    FMSO    would    be   in    a  much    more    disrupted    state    than 
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when    he    took    ever.       In    fact,    the    same    would    probably    be    true 
of    his   successor,    and   it    would   not    be    until    the    third    CO    in 
the    sequence    that   we    would   begin    to    see   payoffs    from    some    of 
the    productivity    measures    we   will   recommend    (about    five 
years  out).      FMSO   is    already   engaged    in   a    number    of   steps    to 
solve  the    problem  areas    we  observed.      Things    seemed  to    be 
moving   in    pesitive   directiens    and   the    management    was    well 
aware  of    the   challenges    facing   befcra    this    report    was    writ- 
ten. 
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Chapter    2 
APPROACHES    IN    IMPROVING    PRODUCTIVITY 

2.  1         I  ?_li?  QD  OCT  I CN 

There    are    many  possible  approachs   to   improving    productiv- 
ity   in   software    development.      There    is    no    one    magic  techni- 
que   that    will    guarantee    results    under    ail    conditions.       The 
most    effective   techniques    to   apply    in    improving    productivity 
will    depend   on   the  current  status   of   the    organization,    its 
level  of    expertise,    and    the  type    of   systems    and    management 
environment    in    which    it    operates.       In   addition,    the   ap- 
proaches   to   productivity    improvement    given    in   the    literature 
tend    to    be    interdependent.      They    cannot   be    applied   separate- 
ly   or    piecemeal    and    have    any    chance    of   achieving   success. 
For    example,    modern    software    management   techniques    cannot    be 
used    effectively    in    an   antique  computing   enviroment.       Most 
of    the   productivity    improvement    techniques    are    highly    depen- 
dent   upon    interactive   computing    environments,    sophisticated 
development   tools  and   the    ability   to    transfer    both   develop- 
ment   code    and   administrative   data   quickly    among   the  individ- 
uals   involved    in    a   project.      On    the   other    hand,    high    tech- 
nology by    itself    is    no  guarantee    of   a    productive 
environment.       A    productivity    improvement    program   needs    a 
well    thought    cut    managment   plan    combined    with    the    latest 
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technology.      In   this    document.,    we  will   try    to   lay   oat    the 
aspects    of   a    productivity    enhancement    program    for    FMSO. 

2.2         PROBLEMS    IN   DEFINING    PRODUCTIVITY 

The   first    problem    with    productivity    in    a    software    envi- 
ronment,   is    deciding    what,    it   is.       This    may    sound   odd   at    first 
because   everycr.e    thinks    that   they   know   what   productivity    is. 
In    a    manufacturing  environment   such   as   the    automobile    indus- 
try,   it    is    not    too   hard    tc  come    up    with   definitions    for    pro- 
ductivity.     An   autsmcbile    is  a   tangible   item.       It    either 
works,  .or    it    dees  not.      It   is    built    from    components   that    are 
easy    to    cost    cut    and    a   cost   for    its    production    can    be    com- 
puted  fairly    readily. 

In   software    development,    this    is   not   the   case.      It    is 
hard    tc    come    tc    some    sort    of    solid    analysis    as    to    just    what 
is    being    produced  by    programmers.       In    ens    ssr.se,    it   is    not 
too    different    frcm  the  case  of   an  automobile.      Programmers 
produce    programs,    and   these   programs    either    work,    or    they   do 
not.      But    each   programmer    wcrking   on    a    system    produces    only 
a    piece    of    it,    and  there    is  no    set    standard    for    measuring 
what    these    pieces  are.      The   measure    most    commonly    used    in 
industry    is   lines  of    code.    All   we   have   to    do    is    count    the 
lines   of    cede    produced   by    a   programmer,    and    divide    that    into 
the    cost    cf   supporting   the   programmer,    and    we    have   a    produc- 
tivity  figure   that   we   can    use. 
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But   when  on?    begins   to    examine    both   the    published    litera- 
ture   and    the    possibilities  available    in   the    definition    of 
lines   of    code,    one's    confidence    in    this   measure    begins    to 
slip    away.       For    instance,    what    do   you   count?    Is    every    com- 
ment   line    in   a    program  counted,    or   do    we    only   count   executa- 
ble   code?      Do    we    count   the   lines    in    a    program    that    contain 
commands    to   the    operating    system,    or    do   we    only    worry    about 
the    source    language    code?      What    do    we    do    about    code   that    has 
been    produced    for   another    system    and   has    been    re-used    for 
the    system    that    we   are  trying   to    analyze?      Can    we    count    code 
that    has    been    produced   by    a   program   generator?      The   list    of 
possible    questions   is    almost    endless. 

One   reply    to    this    is    that   it    does   net    really    make    too 
much    difference.      All   we    have    to    do    is   choose    some    reason- 
able   measure    and    stick    with   it.       Indeed,    this    is    what    most 
organizations    do.      But,    this   does   make    it    hard    to    compare 
productivity    across    organizations.       It    is    not    uncommon    to 
find    "productivity"    differences    that    are    almost    an    order   of 
magnitude    apart    in  comparing   two    different    software   organi- 
zations1.      In    many  cases,    much   of   this    difference    in    produc- 
tivity comes    from  differences    in    the   counting  conventions 
that    are    applied    to    computer  code.      It    would    be    a    mistake    to 
accept  these   differences    at  face    value   as    true   differences 
in    productivity. 


1    See   Barry   Bcehm,    Software  Engineering   Economics,    p.    86    for 
a    table    listing  the   different    effort    models    and    a   brief 
comparison    cf    the    number  of    man-months    predicted   by    each 
for  a   software    development    project. 
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There    are   ether  possibilities    fcr   measuring   the   output   of 

a    software    effort.      It    is    possible    to    define    -he    basic    func- 
tions performed    in  a    program,    and   then   count    productivity    as 
number   of    functions    implemented2.       Another    possibility    would 
be    to   count    number  of    programs   released.       Both    of    these    are 
somewhat    grosser    measures    than   lines    of   code,    ar.d    in    their 
own    way,    they   can  be    as    hard    to    implement.       No    matter    what 
measure    is   chosen  for   productivity    in    an   organization,    care 
should  be    taken    in   its  application.       One    does    not    want    to 
come    up    with    a    measure   that   encourages    behavior    that    is 
counterproductive.      For    example,    if   one    chooses    lines    of 
code    as    a    measure  then   checks    should    be    made    from    time    to 
time   to   make    sure  that   this  is  not    encouraging    programmers 
to    use   coding    techniques    that    maximize    lines    of    code.       Simi- 
larly,   if    one    choose    programs    released    as    a    measure,    then    it 
would  be    to   a    programming    team's    advantage    to   only   try    to 
work    on    short,    simple    systems.       This    would    boost    their    "pro- 
ductivity"   measure  as   defined    by    the    organization.       Whatever 
measure    is    chosen,    it    should    be    applied   with    common   sense, 
examined    frequently    and    compared    with    other    measures    of    pro- 
ductivity.     Slavish    adherence   to    an    inappropriate    productiv- 
ity   measure    could  do    more    damage    to    real    productivity    than 
not    paying    any  attention    to  productivity    at    all. 


2    For   an    example    of    this    approach,    see    the    article    by    A.    J. 
Albrecht,    "Measuring   Application    Development    Productivi- 
ty". 
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2.3         PRIORITIES    IN    IMPROVING    PRODUCTIVITY 

In   improving   programmer   productivity   at    FHSO,    we   have    a 
few    problems    because    'here   is    no    currently    accepted   defini- 
tion   of    productivity    in    place    at    FMSO.      Ihis    means    that    we 
could   institute    programs    fcr   productivity    improvement,    but 
we    have   no    way   cf  measuring  how    well   these    programs   perform 
One    approach   to    this    problem    would    be    to    set    up    some    produc- 
tivity measures,    gather    data    and    use   this    data    as    a   bench- 
mark   for    future    productivity    enhancement   measures.      We    feel 
that    this    would    be   a    bad    approach.      The   problems   that    FMSO 
has    are    serious    enough,    and   the    organization    is    enough    be- 
hind   the    current    state   of    the    art   in   information    systems 
technology    that    we    feel    that    certain    measures    must    be    taken 
without    delay.      In   setting   up   a    productivity    improvement 
program    at    FMSC,    we    feel    that    the    following   areas    should    be 
considered    {in    order    cf    priority) : 

1.  Automation  of    the    systems    development    process. 

2.  Improvement   of    the    physical    environment    at    FMSO. 

3.  Development  of   a    system   of    productivity   measurement 
and   data    gathering    to   support    this    system. 

4.  Development  of   a    system   for    project    planning   and 
tracking   based   on    the    productivity    measures  devel- 
oped. 

5.  Continue    the    work    on  a   set   of   automated   development 
tools    in    support    of  the   systems   development    effort. 
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All  of  these  problems  are  serious,  and  to  a  certain  ex- 
tent, they  must  all  be  attacked  simultaneously.   We  feel, 
however,  that  the  automation  of  the  software  development 
process  is  the  most  important  issue  to  be  solved  in  the  near 
term.   The  highest  priority  should  be  given  to  the  acquisi- 
tion of  a  development  tools  system  to  aid  in  both  software 
development  and  project  management.   A  major  problem  at  FMSO 
is  that  development  takes  place  on  "test  bed"  machines. 
Such  machines  are  set  up  tc  meet  the  needs  of  the  organiza- 
tion for  which  the  software  is  being  developed.   They  do  not 
have  the  full  set  of  software  aids  that  one  would  expect  en 
a  modern  software  development  facility  (sophisticated  text 
editors,  interactive  compilers,  file  transfer  protocols, 
message  handling  facilities,  and  word  processing  text  for- 
matters) .   These  tools  are-  not  necessary  for  the  ultimate 
missions  of  these  test  bed  machines.   However,  these  auto- 
mated tools  are  very  effective  for  software  development  and 
project  management.   Further,  because  the  development  ma- 
chines are  identical  to  the  actual  production  machines,  the 
temptation  to  pre-empt  development  activity  if  one  of  the 
production  machines  is  down  is  very  strong.   The  immediate 
needs  of  users  naturally  have  a  higher  priority  than  long 
term  development  projects,  and  this  can  result  in  slowdowns 
in  development.   The  "test-bed"  machines  are  actually  the 
production  machines  of  the  development  groups,  but  users 
tend  to  overlook  this.   It  must  be  recognized  that  software 
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envelopment    is   a    highly    specialized    activity,    and    that    it 
needs  its    own    production    facility.      Ther  =    is    no    reason    why 
the    development   system   has  to    be    the   same    machine    as    the    one 
for    which    the    software   is    being    developed.       In    fact,    devel- 
oping the    software   on   a    different    machine    could    actually 
serve   to    make   the  code   more   readily    portacle. 

2.4  THE    CASE    FOR    A    DEVELOPMENT     TOOLS    SYSTEM 

The  development   tools    system    should   serve    both    management 
and    programmers.      It    is    hard   to    separata    the    needs    of    the 
programmers   and   the    project  managers    in  a    large   software    ef- 
fort.     If    anything,    the    larger   the   software   effort,    the    mere 
time   and    effort    will    be    spent    in    management    and    documenta- 
tion   issues.      For  a    large    system,    actual    coding    is    likely   to 
consume    about    30%  of    the    effort.       The    remaining    effort    is 
spent   in    documentation,    management   and   coordination   of    the 
diverse    elements    making    up  the   system.      Any    development 
tools  system    inplemented    should    be    able    to    support    these 
needs.      A    unified  development    tools   system    should    be    able   to 
support    these    functional    areas: 

1.  Development    documentation. 

2.  Project    management    and    tracking. 

3 .  Budgeting. 

4.  Program  coding. 

5.  Program   testing. 

6.  Database   development  and    program   test    data. 
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7.   Quality  assurance. 
To  those  used  to  older  generations  of  equipment,  this  may 
sound  like  an  impossible  list  of  tasks  for  a  single  comput- 
er.  In  fact,  this  list  is  the  rule  rather  than  the  excep- 
tion en  modern  large  scale  computers.   Most  mainframes  offer 
a  wide  variety  of  tools  that  will  supper-  this  type  of  envi- 
ronment . 

The  processors  needed  to  support  systems  development  in- 
clude: 

1.  Interactive   compilers. 

2.  Languages    with   string    processing   capabilities. 

3.  Text    processing   packages    for    formatting    documenta- 
tion. 

4.  Sophisticated    file    handling    capabilities. 

5.  Screen    oriented   text  editors    for   manipulating    both 
cede    and   text. 

6.  The    ability   to   transfer   data    from    one    user    to    another 
quickly   and  conveniently.       This    would    be    used    for 
both   automated   office    type   applications   and   program- 
mer's   work  b en ch. 

7.  Packages    for    doing    statistical    analysis. 

8.  A    graphics  system    for    producing   documentation    and 
management  reports. 

9.  Automatic    typeset    facilities    for   producing    "clean" 
documentation    and    reducing   printing   costs. 
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The    idea    is   -hat    a    development    system    should    support    a    wide 
variety   of   both   computer    related    and   management    related   ac- 
tivities.      Some    may    object   to    the    proposal    that    text    pro- 
cessing   abilities  should    be  included   on   the    development    sys- 
tem.     The    counter   argument   would    run   -    "We    already    have    word 
processing    facilities.      Why  buy    more?".       What    we   are    propos- 
ing   here    is   somewhat    different    from   the   normal    word   process- 
ing   systems.       The  development    system    would    be    used   to    tie 
together    a    number  of    different    applications,    and   word    pro- 
cessing   would    be    one    of    them.      It   is    very    convenient    and 
cost    effective   to   be    able    to    do    both    programming   and    word 
processing   on    the   same    machine.       For   one    thing,    it    allows 
you    to  take   the    output   of    a  program,    reformat    it    and    use    it 
as    part    of    the   text    ir.  a    manual.       This   is    difficult   to    do    on 
an    ordinary   word    processing  system    because    it    involves    re- 
entry of    data   that   was   already   generated    by   the    computer 
anyway.       The    strategies    for   building   a   development    system 
are    discussed    in   Chapter    3. 

2.5         IMPROVING    THE    PHYSICAL    PLANT 

Almost    as   important  as   the    acquisition    of    a    development 
tools  system    is   improvement  of  the    programming    environment 
at    FMSO.       The   present   facilities    are   inadguate    for   any    type 
of    clerical   wcrk,   particularly  computer  programming.       FMSO 
is    housed    in   an   old    warehouse   building.      The    space   inside 
the    building    is    broken  up    using    shoulder    height    partitions. 
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These  partitions   are    of    the  old- fashions!    sort    that   do    net 
provide    much   sound   insulation.      The   building    itself   is    noisy 
and    poorly    air   conditioned.      This   is   the    worst    environment 

for    software    production    that    we    have    ever    seen. 

The  present  facilities  provide  about  50  square  feet  of 
floor  space  for  each  employee.  In  the  computer  industry, 
100  square  feet  is  considered  normal3.  Programming  is  an 
activity  that  requires  scnewhaf  different  types  of  office 
spaces  than    a   other    clerical    jobs.      The   by-products   of    com- 


puter  programming    (li 


1  i  st  i  n 


:,    sheets    cf    graphics    output,    man- 


ual   libraries)    take    up   a    great    deal   of   work;   space   and    stor- 
age   space.       To    use  them    effectively    requires    specially 
designed    work    areas    and    storage    areas.       A    programmer    needs    a 
desk*   for    normal    work,    a    work    table   where    he   car.   spread    out 
listings    or    notes   for   work    (even    with    a    more    modern   system 
that   de-emphasizes  hardcopy,    it    will    be   a    while   before    all 
programmers   accustom    themselves    to    this) ,    a    terminal    for    in- 
teraction   with   the  computer  and    storage   areas    for    listings 
and    manuals.       It    goes    without    saying    that    this    all    should    be 
in    the   context   of  a    physically   comfortable    environment.       The 
air    conditioning    should    be  adequate    to   the    climate,    and   the 
sound  insulation    should    be   good.       In   addition,    there    have    to 
be    conference    facilities    raadily    available    for    meetings   of 


3    See   the    description    of    the    IBM    Santa   Teresa    labs    which 
were  specifically    designed   to    support   software   develop- 
ment.      The   reference   is    G.    M.    McCue,    "IBM's    Santa   Teresa 
Laboratory   -    Architectural  Design    for   Software   Develop- 
ment". 
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project   teams.      Program    development   for   a    large   system    is   a 
relatively   social  activity,   and    this    meeting   space   is    needed 
for    the    job   as    well.       The    ccmiiiand    seems   to    be    well    aware    of 
the    space    problems   and   is    taking    steps   to    remedy    them.       Seme 
of    the  problems    will    be   alleviated    in    the    future   as   systems 
work    moves    away    from    cards  and  the    floor    space   taken    by    card 
files  can    be    reclaimed. 

The   issue    cf    programming  environment   is    an    important   one 
and    is   addressed    in    Chapter  4.       There    are    no    specific    stud- 
ies  relating    programming    environments    to   productivity.       As 
we    discussed   earlier,    productivity    measures   are    rather    rub- 
bery,   and    it    would  be   statistically  difficult   to   relate   spe- 
cific productivity  measures  to   ail   cf   the    possible   variables 
in    environmental    design.       Still,    if    your    building    layout    is 
substantially    at    variance    with   what    is    considered    normal    in 
the    the    industry,   then    your   programmers   are    likely   to    no- 
tice.     FMSO   is  ringed   by    software   houses    (EDS,    CACI  and   oth- 
ers) ,    and    the    program  development   environments    there   are 
likely  to    come    a   lot    closer  to   industry   norms   than    they    do 
at    FMSO.       Eventually    FMSO    is    going    to    lose    many    of    its    best 
employees    to    these  organizations   because   they   perceive    a 
better  environment  there.      It    is    a   tribute    to   the    management 
practices    in   place  at   FMSO  that    the   employee    morale   is    as 
good   as   it   is. 
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2. 6         CONCLUSIONS 

The  observations    we  have  made    in    this    chapter    should    corns 
as    no  surprise.      From   our   conversations   with    FMSO    staff, 
these   are    well    kncwn    problems.       They   do   not    seem    to   be    wide- 
ly   known    outside   the    organization,    however.      He    feel    that 
FMSO    is    at    a   crucial    point  in   its  existence.       It   has    to    ei- 
ther   improve    its    technical   and   physical    facilities,    or    it 
will    cease    being    a   viable    software    development    organization. 
The    options   are    either   to    improve    the    facility    or    to    abandon 

•   J. 
—    -  • 

The   process   of  productivity   improvement    must    be   attacked 
on    several    fronts.      The    most    important    is    the    improvement    of 
the    technical    and  physcial  environment.      It    does   not    make 
sense  to    try   to    implement    modern    software    management    techni- 
ques   in    a    horse   and    buggy    technical    environment.      The    im- 
proved software    management   techniques    will    be    helpful    in    any 
environment,    but    they   will  not   be   as    effective    on   a   non-in- 
teractive,   antique  computer  system.       Along    with    the   improve- 
ment   of    the   system,    an   acceptable    measure    of    productivity 
must    be   developed  and   installed.       All    of    these    changes    are 
evolutionary,    and  will   tak-  a    good    deal   of    time.       There    are 
no    generally    accepted   productivity   measurement   techniques    in 
industry.       The    models    used   tend    to    be    tailor    made    for    each 
organization,    and  the    same   will    be    true   for    FMSO. 
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Chapter    3 
REQUIREMENTS     FOR     A    DEVELOPMENT    TOOLS    SYSTEM 


3.  1         INTRODUCTION 

Sir.ce    the    Development    Tools    System    is    to    be    installed    in 
a    Navy   environment,    the    first    thing   to   consider    is    the    pro- 
curement   cf    this    type    of    eguipmant.      To   somebody   accustomed 
to    industry   standards    for    software,    the   lead    times    for    gov- 
ernment   software    procurements    seem   excruciatingly   long.      The 
ICP    Resolicitation  effort    at    FMSO   has    been    going   on  for 
eight   years   new,    and    the    first   machine    has    yet    to    arrive. 
In    industry,    eight   years    would   be   the   complete    life   cycle 
for    the    system    from    the    first    feasibility    study    to    the    final 
departure    cf    the    system    at   the   end    of    its    life.       In   the 
past,   such    long    life    cycles  have    guaranteed   that   the   equip- 
ment   will    te    obsolete    when  installed. 

Part  of  the  problem  is  that  a  great  deal  of  economic  jus- 
tification is  required  for  a  government  procurement.  There 
is  nothing  wrong  with  this  per  se,  but  this  economic  justi- 
ficatation  is  always  tied  to  a  specific  shopping  list  of 
hardware,  and  the  whole  thing  has  to  go  through  many  levels 
of  approval.  Meanwhile,  the  computer  industry  changes  at  a 
rapid  pace,  and  the  list  of  hardware  quickly  becomes  obosc- 
lete.      It    would    be   worthwhile    to    consider    the    approach    taken 
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by    the   SPLICE    project    in    acquiring    a   system.       The    focus 
should   be    en    the    functions   that    they   system    is    to    serve    and 
not    en  the   specific    list    cf  hardware   to   accomplish   those 
functions.      The    system    itself    should    be   modular    and    expanda- 
ble.     Once   a    procurement    authorization   is    in    place,    it    can 
be    used    as    a    vehicle    for    future    upgrades    to    the    system. 
This    is    being   done   in   current   Navy    procurement    (including 
the    IC?    Re solicitation)  ,    and   it    may    help    to   relieve  some    cf 
the    past    problems.      The    procurement   document    is    regarded    as 
a    vehicle    for    future    upgrades    and   the    need    for    re- justifica- 
tion   of    upgrades    should    be   avoided.      The    same    sort    cf    focus 
should   be    used    in  the    acquisition   of   a    Development    Tools 
System. 

3. 2         FUNCTIONAL    CAPABILITIES    RE2£IHED 

The  functional  capabilities   in   the    Development    Tools    Sys- 
tem    should    include: 

1.  Interactive  compilers   and    debugging    tools   for   system 
development    in   the    major    languages    used    at    FMSO. 
This    would  be    CO  SOL  and    perhaps    FORTRAN. 

2.  Interactive  languages    with   good    string    processing    ca- 
pabilities for   use    as   tool   generating    languages. 
These    would   be  used   to   generate   data    bases,    and    de- 
velop   automated   tools    for    analyzing    computer  code 
(structure   and   standards    checkers    would    be    two    exam- 
ples) .      Good    candidate    languages    would    be    PL/I    or 
Pascal. 
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3.  High   speed  terminals  with    full  screen    editing   capa- 
bility.     Ideally,     there  should    be    a   terminal  for   each 
prcgra  miner. 

4.  An    electronic    mail    system    so   that    programs,    documen- 
tation   and  data   could   be    routed   readily   among    the 
members   of  the   development    team.      Such   a    system    could 
serve    as    the    foundation   of   the    development    and    man- 
agement  work    on  FMSC  systems. 

5.  A    variety    of    management   tool    aids    such   as    statistical 
packages    (SPSS,    Minitab)  ,    management    packages    (PERT) 
and    report  generating    packages    (B4MIS    II    or    FOCUS)    to 
aid   in    controlling    the    development    of    FMSO    projects. 

6.  A    sophisticated   word   processing    capability    that    would 
include    the  ability  to   format   large    documents    (the 
requirements    tend    to   be    different    than    for    small    word 
processing  systems).      Examples    of    systems   of   this 
type    would  be    Script  or   ATMS. 

7.  A    sophisticated   graphics    capability    for    producing 
both    documentation    and    management    reports. 

8.  An    automatic    typesetting    system    tied    in    with  a    high 
speed    laser  printer. 

This    is    a    formidable    set    of  requirements    for    a    single    ma- 
chine.     A    number    of    manufacturers   supply    equipment    that 
could  handle    these  requirements,    but   it   would   probably    be 
more    economic  to   consider    a  Local   Area   Network    (LAN)    rather 
than    to    try   to    satisfy  all  of    this    on    a   single    machine.       The 
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networking    system  chosen    would   be   the    vahicle    for    future 
system   growth.      Increments  to    this    computer    power    could    be 
added   as    needed. 

At   the    base   of   this   network,    there    would    have   to   be    one 
or    mere    reasonably   powerful  mainframe    systems.       These    would 
be    reguired    for    implementing    programming   tools    and   for    doing 
interactive    testing    of  code.      Individual    editing   and   word 
processing    functions    could  probably    be   handled   en    smaller 
"smart"    terminals.      It    makes    ioes    sense    to    download   process- 
ing   onto    cheaper    micros    and  minis  rather   than    trying    to    find 
a    large   CPU   to    handle    everything. 

3.3         COST    JUSTIFICATION    FOR    THE    DEVELOPMENT    TOOLS    SYSTEM 

It   will    be    difficult    to   do    traditional    economic   analysis 
on    such    a    system    for    cost    justification.       The    normal    govern- 
ment   approach   to   economic    analysis    on   systems   is   to  deter- 
mine   requirements,    cost    out  a    set   of    alternatives    for    meet- 
ing   those    re3uirements   and  then    choose    the    most    cost 
effective    alternative   for   the   system.      There    is   nothing 
wrong   with   this,    but    it    does    make   one    rather    large   assump- 
tion   at    the    start   -    namely  that    you   can    determine    your    "re- 
quirements'1.     In    FMSO's    case,    this    will   simply    not    be    true. 
The    software    development    environment   there    is   so   far    behind 
current   technology   that    the   programmers   could    not    even    state 
exactly    how   they    will   use    the    new    system.       Our    experience    at 
NPS    is  probably   instructive.      3efore   we   acquired  cur   IBM 
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3033AP  system,  we  went  through  the  standard  justification 

and  benchmarking  based  on  the  best  guesses  we  could  come  up 
with  on  how  users  would  use  the  new  machine.   These  guesses 
proved  to  be  totally  inadequate  because   our  users  were  very 
quick  to  come  up  with  unanticipated  uses  of  the  machine. 

This  is  the  problem  of  trying  to  assess  "unmet  demand"  in 
advance.   In  FMSO's  case,  the  problem  is  likely  to  be  an  or- 
der of  magnitude  worse  because  the  systems  in  place  there 
are  so  old.   It  will  take  the  programmers  at  least  a  year 
before  they  begin  to  feel  comfortable  with  the  machine. 
Once  they  do  feel  comfortable  with  it,  they  will  begin  tc 
use  it  in  ways  that  are  hard  to  anticipate.   A  LAN  type 
technology  will  at  least  allow  ycu  to  expand  your  resources 
in  a  modular  fashion. 

3.4    CONCIDSICNS 

FMSO  should  try  to  remain  as  flexible  as  possible  in  its 
acquisition  of  a  Development  Tools  System.   Fortunately, 
this  is  relatively  easy  to  do  with  newer  computer  systems. 
It  is  possible  tc  buy  a  system  as  a  set  of  building  blocks 
and  integrate   and  expand  the  system  over  time  by  adding  new 
pieces.   FMSO  and  the  Navy  generally  need  to  change  the  way 
they  think  about  computer  systems.   A  computer  system  is  not 
a  solution  tc  a  problem.   This  type  of  thinking  leads  plan- 
ners to  believe  that  a  particular  system  is  good  now  and 
forever.   A  ccmputer  system  is  a  part  of  a  problem  solving 
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process.       As    the    process    changes,    it    is   probably    a    good    idea 
to    consider   changing    the    system    as    well.       NA VSUPSY3C0M    has 

failed  to    do    this   with   its  computer   systems,    and    it    will    be 
a    difficult,    expensive  process   to   upgrade. 

Newer    trends    in   Navy    procurement    make    it    easier    to      ac- 
quire  useful    computer   systems    by    focusing    on    the    functions 
provided    by    the    system   rather    than    on    a   shopping    list    of 
computer    hardware.      FMSO    needs   to    look    at    developing    an    in- 
tegrated  system    that    will    support   program    development,    docu- 
mentation,   tools    development    and    management.       The    system    de- 
veloped   shcuid    be    expandable    so    that    the    system    can   grew    as 
FMSO's  needs    grow.      The    most    promising    candidate    for    this 
type    of    system    is  the    local  area    network    approach.      The    LAN 
technology    is    still    fairly  new,    and    it    m«ay    be   a    few    y^ars 
before    there    are    any    clear   leaders    in    this    field.      In    the 
meantime,    FMSO   shcuid   begin   working    en    an    overall    develop- 
ment   plan    and    begin    acquiring    equipment    that    could    provide 
short   term    aid   and  also    be  rationally    fitted    into    a   LAN    de- 
velopment   in    the    future. 
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Chapter    4 
PROGBAHMING     EN7I50NMENTS    AND    PRODUCTIVITY 

a  •  1  I5IJCDUCTION 

The  concept   of  program ling   environments   is   one  -hat    is 
just:    beginning   to  get  attention    from   researchers   in   produc- 
tivity.      The    development    cf  computer   software   is   still    in   a 
cottage    industry    phase.    It  is   not   unusual    for    a    programmer 
to    have   to    write   the    code,    keypunch   it    (or    do   the    data    entry 
on    a    terminal),    document    it,    keep   track   of    modules,    inte- 
grate  modules,    test    the    modules,    assemble    the    release    pack- 
age   and    a    number    cf    other    chores    associated    with   the    pro- 
ject.     This    would  be    similar    to    having    an    automotive    worker 
be    the   designer    cf   a    car,    write    the    owner's    manual,    assemble 
the    car    and    be   responsible  for  doing   maintenance   work    on    it. 
This    would    require   personnel   who    were    much    more    skilled    than 
current    autornc*ive   service   personnel,    and    cars    would    be    a 
great  deal    more    expensive   as  a   consequence. 

This    problem    that    programming    work    has    is    just    an    example 
of    general    problems    in   the  clerical   area.      Capital   expendi- 
ture   per    worker   is  lower    for    white   collar    workers    than    for 
any    ether    type.      The    average   per    capita   capital    expenditure 
for    white    collar    workers    in  our    economy   is    $3,000.      The   cor- 
responding   figure  for   blue  collar    workers    is    $25,000   and    for 
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farm    workers   is    $35,000.       Productivity    is    harder   to  measure 
in   clerical   areas.      Perhaps  part    of   the   problem   is   that    man- 
agers  feel    that    office   workers  are   not   rsaiiy   producing   any- 
thing  anyway,    so    why    spend  any    money    on   them.       This  attitude 
is    crumbling    in    the    face    of  office    automation,    but    it    will 
be    a    while   before   it    disappears. 

H.2         ELEMENTS    OF   A    PHOGRAMMING    ENVIRONMENT 

When    we   talk    about    a    programming    environment,    we  are 
talking    about    a    whole    complex    of    support    facilities   for    a 
programmer.      Specifically,    the   points   covered   in   the   idea 
include : 

1.  Tools    support    -   access    to    convenient,    up    to    date 
technologies . 

a)  Interactive    systems. 

b)  Flexible    lata    editing    facilities. 

c)  Text    formatting    and    document    preparation. 

d)  Electronic    mail. 

e)  Interactive   compilers. 

f)  Flexible  interactive   terminal   systems. 

2.  Architectural    environment . 

a)  Comfortable    workspaces. 

b)  Adeguate  storage    for   documentation    and   listings. 

c)  Library  facilities. 

d)  Conference    and    meeting    facilities. 

3.  Team   support. 
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a)  Eat. a  entry  personnel. 

b)  Program  and  data  libararians. 

c)  Technical  writers. 

d)  Management  aides. 

e)  Adequate  secretarial   support. 
4.      Social   support. 

a)  Professional  development    seminars. 

b)  Training   opportunities. 

c)  Access    to    technology. 

The    requirements   of    a   programmer    in    a   systems   development 
environment    are    basically    threefold.      Thsy    are: 

1.  Privacy    for  program   writing    activities. 

2.  Meeting   areas    for    social    interaction    on    project    work. 

3.  System    access    for    program    testing. 

Anything    that    undermines    these  requirements    will    undermine 
the    programming    environment  generally. 

*-3  IMPROVEMENTS    II    PHODOCTiyi  TT    DOE    TO    IMPROVED 

ENVIRONMENT 

?rom    FMSO's   point    of    view,    the    most   interesting   question 
is    how   much    productivity    will    be    improved    by    improving    the 
development    environment.       This    will   be   necessary   for    any 
cost    justification   of   improvement.       It   turns    out    that    this 
will    not    be    an   easy    question   to    answer   for    a    variety    of   rea- 
sons.     First    of    all,    there  is    no    real   system    of    productivity 
measurement    in    place    at    FMSO,    so    we    have    no    way   to    measure 
productivity.      Secondly,    FMSO    is    a    unique    environment.      In 
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most    ways,    it    is    far    behind  current  computer    technology.      It 
is    doing    development    in    a    computer    environment    that   most    or- 
ganizations  scrapped    tan    years   ago.       Its    management    climate 
is    mere    up    to    date.       The    improved    programming    technologies 
are    given    in    the    development    handbooks,    the    staff    is    aware 
of    them    and    seems  dedicated  to   implementing    those    that    can 
be    adapted   to    FMSO' s    situation. 

It   is    this    combination    of    factors    that    makes    comparison 
with    industrial   experience   difficult.      Most   of   the   research 
on    productivity    improvement   dials    with    the    improved   program- 
ming   technologies.      There    is    little    work   done    on    a    compari- 
son   between    interactive    vs.    batch    modes   of    program    develop- 
ment.     The    reason   for   this   is    simple.      Everybody   considers 
interactive    ceding   to   be    such    an    improvement    that    ncbody    has 
bothered    tc    research    the    question   lately.       There    were    a    few 
tentative    papers    en    the    subject    in    the    late    1960*5,    but 
there   has    been    little   recently*. 

The   programming  styles    cf    the    workers    will    be   different 
in    interactive   environments  than    they    will    in    a    batch    envi- 
ronment.      When   a    programmer   does    development    work    in    a    batch 
mode,    he    has    tc    keep    several    projects    going   concurrently. 


♦  See  Harold  Sackman's  article,  "Explo 
Studies  Comparing  Online  and  Offline 
ance"  published  in  the  Communication 
for  CorajDutin.g  fl ac h i ne r y  in  January  1 
cle  concluded  that  there  was  about  a 
programmer  time  usir.g  an  interactive 
noted  that  study  used  the  relatively 
systems  cf  the  late  1960's.  Today's 
terns  are  orders  of  magnitude  better 
active    systems. 
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This    way,    he    has    something   to   do    while    waiting    for   the    out- 
put   of  his    last    computer    run.      This   also    means   that   there    is 
a    setup   cost    each  time   he    shifts    gears    from    one    project    tc 
another.       In   an    interactive  environment,    a    programmer    is 
able    to    concentrate    on  a    single    project   until   it   is  complet- 
ed.      He    does    not    have   to    clan    his    work    ground   the    difficul- 
ties  of   computer    access.       This   would   suggest    that    interac- 
tive   systems    development    should    have    high    payoff    in   a 
maintenance  oriented    environment    like    FMSO's.      For   most 
maintenance    work,    the   changes    to    a    program    tend   to    be    small 
and   could    he    completed   quickly.       An   interactive   system    could 
also    be    useful    in  controlling   the    forms   and   documentation 
associated    with    program    development. 

H .  <4         C0NCID5ICNS 

Mere   attention  needs    tc   be    given    to   the   issue   of  program- 
ming   environment    at    FMSO.      The   majcr   points    that    need    im- 
provement   are   the  physical  and  technical    environment.      These 
have    been    amply   covered    elsewhere.      But   simply   improving 
these   aspects   of    the    environment   is   not   enough.       When    the 
new    system    is    installed,     work   should    also    begin    on    providing 
support    tc   developers   in    the   form   of   improved   tools,    secre- 
tarial assistance  and  general   programming    team   support. 
This    will    allcw    FMSO    to    reap   full   benefit    from   the   new    tech- 
nologies. 
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Chapter    5 
A    PBODOCTIVITY    MEASUREMENT    SYSTEM 

5.  1         INTJCDUCTION 

This    chapter    will    discuss   the    measurement    of    productivity 
within   the   software    development    and    maintenance    process. 
Productivity    measures,    when  defined   as    a    measure   of   output 
divided    by    a    treasure    of    input,    are    used    for    measuring    the 
efficiency   of   any  production    process.      Productivity   measures 
can    provide    information    on  efficiency    at    ail    levels   of    an 
organization.      These    levels   include   various    projects   and    de- 
partments,   as    well  as   the    entire    organization.      This    chatter 
will    examine   the    purposes    of    productivity    measurement,    the 
productivity   measurement    problem    in   general,    various    meas- 
ures   of    programming    productivity    and    a   brief    discussion    of 
the    implementation   of    a    productivity    measurement    system. 

5.2         P21P0S2S    CF   PRODUCTIVITY    MEASUREMENT 

The   primary   purpose   for   measuring   productivity    in    the 
software    development    and    maintenance    process    is    to    provide 
information    for    use    in    the  three    major   phases    of   software 
management.      These   phases    are   the   planning,    control   and 
evaluation   of   the  entire    software   process    as    well    as    indi- 
vidual projects    within  the   process. 
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5. 2.  1        Planning 

The  primary   function    of  the  planning  phase   of   software 
management    is  to    provide    a  prior    estimate    of    resources    re- 
quired  for    supporting   The    software    development    and   mainte- 
nance  process,    either  on    a   project    basis    or   on   a   recurring 
basis   for    the   entire    software    department.       The    planning 
phase  allows    for    the    establishment    of    budgets    for   the    de- 
partment   and    projects   as    well   as    subbudgets   for    each    of   the 
input  factors,    especially    labor,    which   are   required  in    the 
software    process.      The   productivity  measure    is    used,    along 
with    an    estimate    of    the    amount    of   output    r^guired    for    the 
project    or    department,    to    generate    an    estimate    of    the    amour.- 
of    input (s)    required    for    a  given    time    period.      It    should    be 
noted   that    there    exists    a    direct    link    during    this    phase    be- 
tween  the    productivity   measure   and    project    cost    estimating 
methods.       Cn    a    project   basis,    the    productivity    measurement 
problem    is    equivalent   to    the    project   cost    estimation    prob- 
lem. 

5.2.2        Control 

The  control   phase    of    software    management    entails   the    de- 
termination  of  the  extent    of   progress    of    the   software    pro- 
cess   and    may    be    applied    at  both    the   department    and   project 
level.      Progress    may    be    measured    on   two    dimensions,    budget 
and   scnedule.      On  the   budget   dimension,    actual   expenditures 
are   compared    with  planned   expenditures   and   variances   are    ex- 
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amined.   Adequacy  of  progress  is  measured  by  these  varianc- 
es.  The  planned  expenditures,  which  were  generated  during 
-he  planning  phase,  usually  serve  as  the  standards  for  meas- 
uring progress.   However,  the  plans  are  subject  to  modifica- 
tion duo  to  unforeseen  contingencies. 

On  the  schedule  dimension,  actual  elapsed  times  are  com- 
pared with  planned  elapsed  times  and,  again,  variances  are 
examined.   As  in  the  case  cf  budgets,  planned  schedules 
serve  as  standards  except  when  modified  by  unexpected 
events.   Productivity  measures  are  used  in  this  phase  to  as- 
sist in  the  determination  of  actual  budgets  and  schedules, 
as  well  as  to  assist  in  the  modification  of  plans  when  con- 
tingencies occur. 

5.2.3    Evaluation 

The  evaluation  phase  of  software  management  concerns  it- 
self with  the  determination  of  how  well  the  software  process 
is  meeting  the  goals  cf  the  organization.   This  determina- 
tion may  be  made  at  the  department  level,  the  project  level 
or  any  intermediate  level.   An  integral  part  of  this  deter- 
mination cf  the  adequacy  of  the  entire  process  is  an  evalua- 
tion of  the  efficiency  of  the  process.   Productivity  meas- 
ures, functioning  as  pure  efficiency  measures,  are  useful 
during  the  evaluation  phase. 
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5.3         PRQDOCTIVI^Y   MEASUREMENT   IS    GENERAL 

Productivity    is  defined   as    the   relationship    between    the 
output   of    goods    and    services   and    the    inputs    used   to   produce 
those  outputs.      Two    general  types   of   productivity    ratios   are 
generally    used:       total   factor    productivity   and    partial    fac- 
tor   productivity    ratios.       Total    factor   ratios    include    all   of 
the    inputs    in    the   production    process,    while    partial   factor 
ratios  do    net.      The    inputs  or    factors    of    production   are    gen- 
erally  classified  into    three    major   categories:    labor,    capi- 
tal   and    materials.       A   total   factor    ratio    may    be    able    to    dis- 
tinguish   subclasses    within  each    of    these    major    categories. 
For    example,    labor   is    not    homogeneous    and    different   types    of 
labor,    such    as    skill    levels,    may    be   appropriate.       Any    factor 
may    be   used    but    labor    is    in  common    usage    as    a    partial    meas- 
ure   with    the    input   measure   generally    being    man-hours    or 
man-years.      Nets    that    the    use    of    partial    measures    may    be 
misleading    since   changes    in  one    input    have    effects    upon   all 
other  inputs   as    well    as    output.      Consequently,    an    increase 
in    output    per   man-year   indicated    by    a    partial   ratio   should 
not    be    interpreted   to   mean   that    the    increase    is    due   solely 
to    the  increased    efficiency  of  labor.      This   is    because    the 
increase    in  output  is  a    result  of   ail   of   the    factors    of    pro- 
duction   working   together. 

Productivity  ratios  are  affected  by  both  short  and  long- 
run  elements.  Probably  the  most  important  of  the  short-run 
elements    is   the    change    in    utilization    of    productive   capaci- 
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ty.       Productivity  ratios    generally    vary   inversely    with 
changes    in    the   degree   of    capacity   utilization    since  the    fix- 
ed   inputs    cannct    be    varied   with    changes   in    output.       Other 
elements    causing    short-run   changes    in    productivity   are    both 
the    level    of   effort    and    the  learning   process    which   occur    as 
individuals   adapt   to    new    methods    and    equipment.       Among    these 
elements    causing   long-run   changes   in    productivity   are    chang- 
es   in   the    quality  of    inputs.      Such    cnanges    are    referred   to 
as    input-augmenting    technological   change.       Perhaps   most    im- 
portant   of   the   long-run    elements   are   changes    in    the   methods 
of    organizing    production.      These    changes    in    the    underlying 
production    function    a:s    a    result    of    such    items    as    changes    in 
the    organizational   structure   cr    changes   in    managerial    abili- 
ty. 

There    are   several    problems    involved   in    the   use    of    produc- 
tivity  measures.      These    center  around   the    measurement    of    in- 
puts   and    outputs    and    -heir  abilities   to   measure    efficiency. 
When    measuring   inputs   for    use    in    a    productivity   measure,    it 
is    desirable    to    ensure   that  only    the    inputs   that    are    actual- 
ly   utilized   in   the   production    process    are    used    in    the    meas- 
ure.      This    is   especially    important    for    the    labor   input    and 
implies,    for    example,    that   only    time    worked   should   be    uti- 
lized  in    the    measure    instead   of    time   paid.       Although    time 
paid    may    be  of   interest    since    it    corresponds    to    the  total 
cost    incurred,    it   is    important    that    such    items    as    adminis- 
trative   time,    etc.    be   separated    out.      This    will    enable    man- 
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agers  to    fccus   more    carefully   upon    the    separate   activities 
of    productive   work  and  other  work.      Also,    it    is    imperative 
that    only    inputs    which  are  homogeneous   ba    aggregated.       Using 
labor  as    an    example    again,    different   skill    levels,    such    as    a 
keypunch    operator  versus    a  systems    programmer,    perform    en- 
tirely  different    tasks   and   should   be   aggregated    only    when 
they   are    occur   within   a    particular    department.      It   is    also 
preferable   to    measure   inputs   in    terms   of    physical    units. 
Value   units    may    also    be    utilized    but    physical    units   should 
be    used    if   avaiiacle. 

A    primary    problem    with    the    measurement    of    outputs    is    that 
convenient    measures    are    sometimes   not    available    either    in 
physical    unj.ts   or  value    units.       This   output   measurement 
problem    occurs   principally   within    public   sector    organiza- 
tions.     In    this    case,    there   is   usually   no    accepted   opera- 
tional definition  of    what    the    outputs    really    are    (national 
defense,    welfare,    etc.) ,    and   the    outputs   are    not    traded    in 
any    markets  so  that    value    measures    are   unavailable,    also. 
Consequently,    most  of   the    output    measures    in    use   are    actual- 
ly   intermediate    outputs    or,   simply,    inputs    to   further    pro- 
cesses.      5ucn   measures  are  weak,    at   best. 

In  the    cases    where    inputs   and    outputs    may    not    be   precise- 
ly   measured,    the    productivity    measure   becomes   susceptible   to 
perverse    incentives    and    gaming.       This   implies  that   the   con- 
trol   and    evaluation    phases  of    management    may    focus    upon 
faulty  indicators.      For    example,    if    the   output   measure    is 
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not    truly    output,    there    is  some    danger   that    generation    of 
input   may    be    encouraged    rather   than    output.      This    increase 
in    inputs    does   not  necessarily  imply   increased   output. 
Also,    use    of    such  measures   may   provoke    the    generation    of 
useless    output.      In    one    instance    in    the    public    sector,    the 
measure    was   sguare   feet    of   buildings   cleaned.      This  resulted 
in    many    areas    being    cleaned  twice   daily   and    some   areas    not 
at    all. 

Another    major    problem    with    productivity    measures   is    hew 
to    deal    with   the    quality    of  output.      Ostensibly,    the    quality 
of    output    should    be    held    constant   in    productivity    measures 
but    changes   in   quality   may   be   difficult   to    measure.      Quality 
changes    can    cause  difficulties   in    both    directions;    quality 
deterioration    may'cause    the  msasure    to   increase,    while    qual- 
ity   improvement    may    cause   the    measure    to    decrease. 

A    final    problem   is    that  changes    in    one    partial    productiv- 
ity   measure   can    be   misleading    concerning    its    effects    upon 
the    entire    production   process.      There   are    numerous    ways   to 
obtain   a    given   output    with  several    inputs.       Technical    effi- 
ciency  exists    when,    at  a    constant   output   level,    reduction    of 
one    input    necessitates   an    increase    in    another    input.       How- 
ever,   economic   efficiency    exists    when    the    relative    marginal 
costs  of   utilizing  ail  inputs   in    production   of    the   output 
are    the    same.      Technical    efficiency    is   required    for   economic 
efficiency    but   not   vice    versa.       Note    that    neither    of    these 
two   concepts   of   efficiency  are  captured  oy    partial   produc- 
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tivity  measures.      Overdepender.ee    upon    partial   measures    for 
control   and  evaluation  can  result   in   under utilization    cf 
particular   inputs  which    leads   to    less   rather    than    more    effi- 
cient use    cf    resources. 

5.4  MEASURING    PROGRAMMING    PRODUCTIVITY 

5.4.1        Introduction 

Keeping    in    mind  the  abeve   discussion  of    productivity 
measures    in    general,    we    can  now    begin   to    discuss   the   soft- 
ware   programming    productivity    problem.      Programming   is    one 
of    the   major    inputs   into    the  software    development    and    main- 
tenance   process.      Note,    however,    that    programming   is    an    in- 
put  to  this   process;    it    is  not   the   output.      The   output    of 
the    software    process    is    usable   software.       Other    definitions 
and    measures    of    this    output  abound    but    all    are    simply    fur- 
ther   derivations   on    this    one   concept.       Most   output    measures 
which  are    currently    being    used   in    programming    productivity 
suffer    from    being  either    pure    or    intermediate   inputs.       Phys- 
ical   measures,    such    as   programs,    do    not    address    the   problem 
that    users    cf    software   are  not    interested    in    programs    but 
are    interested   only    in   the   output   from   the    programs.       Value 
measures,    such  as  revenues  and  sales,    are    available   for    pri- 
vate  sector   entities    but    are   not    availaDle    for    public   sector 
organizations,    such    as   FMSO.      Because   the    definition   of    the 
output    from   the    software    process    is   so   equivocal,    several 
alternative   measures    are    being   utilized   currently.      These 
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generally    cluster  around    lines   of  cods    produced    in    the    pro- 
gramming   process,    functions   which   the    program    performs    and 
functions    which    the    user    performs   when   utilizing  the    pro- 
gram.     Additionally,    most    variations   on   these    measures    use 
some    measure    of    labor   to    generate   a    (partial)     productivity 
measure.       Productivity   measures    using    thsse    three    major 
types  of    output    measures    as   well    as    an    additional    one,    com- 
pleted  projects,    are    evaluated   below. 

5.4.2        Lines    of   Code 

The   productivity    measure   using    lines  of   cede    is    usually 
lines   of    code    per  labor    unit,    where    the   labor    unit    may    be 
man-days,    man-weeks,    man-months,     etc.      Lines    of   code    is   a 
physical    measure;    however,    it    measures   an    input    into    the 
software    development    and    maintenance    process    not    an   output. 
Lines   of    cods    are  necessary  to   produce    a    software    program 
but    cannot    measure   hew   the    program    functions. 

A    major    difficulty  in    implementing    the    use   of   lines    of 
code    as    a    productivity   measur?   is   to    define    exactly   what    a 
line    consists    of.      Programs  consist    of    mere    than    executable 
lines  of    code.      In  addition  to   the    executable   statements, 
there   may    be    jcb    control    language,    comment    statements,    data 
declarations    and    macro-instructions.      Depending    upon    what   is 
or    is  not    counted  as    a    line,    various   measures   of   lines    of 
code    may    differ    by   factors   of   two   or    more. 
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Another    irajor    difficulty  in   using   lines    of    cods    as    a 
measure   concerns   its    poor    capabilities   when    measuring    non- 
coding  tasks.      The  entire    program   development    process    re- 
quires  much    more    than   coding.      Most    lines-of-code    measures 
attempt    to    deal    with    this    by    using    long-run    measures    which 
have   seme    average  amount    of  nonccding   work   built   into    them. 
However,    the    application    of  lines   cf  code    per    programmer- 
month   to    such    tasks    may    result   in    questionable   results    in 
specific    circumstances. 

These    measures  also   tend  to   penalize  higher    level    lan- 
guages.     The    initial    portions   of    the   software   development 
cycle,   such   as  the  determination    of   user   requirements,    spec- 
ifications   and   test    cases,   as    well    as    later    portions,    such 
as    the   writing    of   documentation,     do   not   depend    upon   the    lan- 
guage utilized.      Since  higher   level   languages   tend   to    re- 
quire  fewer   source  statements    to    program   than   lower   level 
languages,    combination  of    the   coding   portion    with   the    lan- 
guage-independent portions  of   development    results    in   an   ap- 
parent  lesser    productivity   when    using    higher    level    languag- 
es.      This    apparent   paradox  exists    because    the   productivity 
measure    is    just    that    and    is  net    a   measure    of    total   cost. 

A    problem    related    to    the  higher    level    language    problem   is 
that    lines    cf    code  does    net  adequately   deal    with   quality 
differentials    in    different  programs.      Some   efforts   have   been 
made    to    permit    the   introduction    of    quality   measures   within 
lines  of    code    via  the   use    of    complexity   metrics.      Because 
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the    field    cf   complexity    metrics    is    still    undergoing  develop- 
ment   with    no   dominant   metric   available,    the   use   of   such    me- 
trics has    not    yet  offered    a  precise    solution    to    the  quality 
measurement    problem. 

The    last    major  problem    with   lines    of   code    is    that    it    per- 
petuates   the    myth  that  coding    is    the    predominant    activity    in 
software    development    and    maintenance.       This    may    have    been 
the    case    in   the    early  days  of    programming,    out   in,    for    exam- 
ple,   modular    programming    there   may    be    no    new    code    created 
during   a    particular    project. 

A    relatively   minor   problem    appears    to    be    that,    when    such 
measures    are   applied    to    subtasks    in   a    project   and    then    ag- 
gregated,   the    aggregation    cf   the    subtask    measures    to   a    sin- 
gle   overall    measure    is   performed    incorrectly.       The    correct 
methcd   of    aggregation    depends    upon    whether    the    subtasks    are 
performed    simultaneously    cr  sequentially.       If    they   are    per- 
formed  simultaneously,    the   aggregate    measure    will    be    larger 
than    any    cf   the   sub task    measures,    and,    if    they   are   performed 
sequentially,    the  aggregate  measure    will    be    smaller   than    any 
of    the   subtask    measures.       Combinations   require    that   sequen- 
tial   subtask    measures    be    aggregated    first,    followed   by    ag- 
gregation   cf   the    remaining  simultaneous  measures. 

As   with    all    productivity  measures,    lines    of    code   is    sus- 
ceptible   tc    gaming.       Programmers    may    be   able    to    generate    ap- 
parent increases    in    productivity    where   none   really  exists    as 
well   as   apparently  prevent   decreases   in   productivity    where 
such    a   decrease    has    actually    occurred. 


-    43     - 


Despite    the    problems    given   above,    lines    of   coda    does    have 
a    major    advantage  in    that    it   is    relatively    easy    to    measure. 
With    judicious   use,    lines    of   cede   may    offer    an    excellent 
method   for    measuring    programmer    productivi ty.       The    following 
statement    illustrates   this: 


There    is    still    a   great  deal    to    be   learned   about 
guality   and    productivity    normalized    against    lines 
cf    code.      We  have   not  explored    the   limits    of 
knowledge,    and    comparisons    between   different    kinds 
cf    programs — with   lines    of    code   counted    the    same 
way    for    both — almost    daily    yield    new    insights    and 
discoveries.      It    is    premature    to    aoandon    this 
method,    just   when   results    are    becoming   encourag- 
ing. s 


5. 4. 3        ?I22£«3   Funct ioas 

A    productivity  measure    has    bsen    proposed  and   tested    which 
is    based    upon    functions    performed   by   tha    program.      The    spe- 
cific  measure    is    labor   units    (specifically,    man-hours)     per 
function.      Note   that    this    is   not    actually    a    productivity 
measure,    but    is   the    inverse  of   a    productivity    measure.       As 
in    the   case    of    lines    of    cede,    program   functions    measures    an 
input  into    the  software    development  and   maintenance   process 
instead   of   an   output.       Although    it    is    aole   to    measure    how   a 
program    functions,   this    measure    does  not   capture   how   users 
evaluate    or   utilize    a   particular    piece   of    software. 


5    This   quote     (page   51)    and  some    of    the   above    discussion    is 
taken    from   Jones,    T.C.,    "Measuring   Programming    Quality    and 
Productivity/'    IBM    Systems   Journal,    Vol.    17,    No.    1,     1978, 
pp.    39-63. 
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Perhaps    the    most    difficult    aspect   cf   using    program 
functions    as    a    measure   is    the    definition   of    a    program    func- 
tion.     Prior    applications    have   been    limited    to    structured 
programming   environments    only.      within   this    structured   ap- 
proach  a    function  is    defined   to    be    a    paragraph.       Depending 
upon    the    particular    language,    a    paragraph    and,    therefore,    a 
function    may    be   a  procedure  or  a     (sub) routine.      This    also 
corresponds   to   the   concept  of   a    module.      Given    a    specific 
method   of    measuring    program   functions,    this    measure   is    rela- 
tively  easy    to   calculate.      Hcvever,    this    measure    is   also 
susceptible   to   gaming,    depending    upon    the    extent    to    which 
the-  individual    programmer    can   control    the    structure   of    the 
program..6 

5.4.4        User    Functions 

A    productivity  measure    has    been    proposed    which    is    based 
upon    external    attributes    or   functions    which    are    activated    by 
the    user.       The    general   approach    in    this   case    is .to    determine 
the    external   or    user-oriented   manifestations    of   any  applica- 
tion   software.      In    practice,    this   is   accomplished    by    count- 
ing   the    number   of  external   user    inputs,    outputs,    inquiries 
and    master    files    delivered  by   the    project. 


6  A  discussion  of  program  functions  may  be  found  in  Cross- 
man,  T.D.,  "Taking  the  Measure  of  Programmer  Productivi- 
ty*"  Datamation,    Say    1979,    pp.     144-147. 
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The    counts    cf    each   of    these   four   factors    may    be    weighted 
to    attempt    to    reflect   the    relative    valua   of   each   to   the 
user.      Aibrecht    suggests    specific   weights    which    were    found 
to    be   useful   in    cna    particular  organization.      Additionally, 
the    weighted    sum    may    be    adjusted    to    account    for    extraordi- 
nary   circumstances.       The    result    is    a    measure    of    function 
counts   for   a   specific   project.      The    actual    measure   utilized 
by    Albrecht    was    hours    worked    per    function    count,    which    is 
the    inverse   of   a    productivity    measure. 

The   measure   of  user   functions    per    labor    unit    offers    the 
considerable    advantage   of    actually    attempting   to    measure    the 
output,    user    functions,    of   the   software   process.       In    this 
respect,    it   corresponds    more   closely   to   a    true    productivity 
measure    than    any    of    the    other    programming    measures    discussed 
above.      Since    it    is    mere    output- oriented,    it    is    much    more 
difficult    to    game  than  any   of    the   other   measures. 

The  actual   measurement    of   user    functions   in    specific   cir- 
cumstances   may    be  nontrivial,    however.      For   example,    it    is 
conceivable    that    one    may    have    a    difficult    time    discerning 
whether    a    particular    function    is    an    input    or    an    inquiry.       if 
a    different    weight   is  allowed    for   inputs    than    is   allowed    for 
inquiries,    the   selection    of  particular   user   functions    may 
have    an    unintended  effect    upon   the    actual    value    generated    by 
the    measurement    procedure.7 


7    User   functions    are    discussed   in   Albrect,    A.J.,    "Measuring 
Application   Development    Productivity,"    Proceedings    of    the 
SHARS/GUIDE^I3M  Application    Development    Symposium,    October 
1979, ~pp7    83-92. " 
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5.4.5  Consisted  Projects 

Another   possible    measure  is   completed   projects    per    labor 
unit.      This    measure    offers  the   advantage   of   being    exception- 
ally   easy    to    implement  and   use.       However,    unless   a   reason- 
ably   large    number  of    different    categories    of    projects    are 
maintained,    this    measure    is  axso    exceptionally   susceptible 
to    gaming.      This    is    especially   true   if   the    individual    to    be 
measured    has    any    input   intc   the    selection    of    which    projects 
are    to   be    programmed    by    whom.      Also,    the    existence   of   a 
large   number   of    categories  compromises   zh~    ease-of-use    ad- 
vantage   of    this    measure.       Similarly,    it    presents   the    addi- 
tional problem   of  ctoss   comparisons  < 
when    looking    at    a  single    programmer. 

5. 4. 6  Summary 

Each    of   the    above    measures    has    unique    advantages   and    dis- 
advantages.     This  ensures    that    there   is    no    one    dominant 
measure    for   all   situations.      Since    FMSO   is    both    a    develop- 
ment   and    a    maintenance   activity,    these    measures    must    be   ex- 
amined  for   their    specific    comparative    advantages    in   the    de- 
velopment   and/or    maintenance    processes.      Along   this 
dimension,    the   two   functional    measures,    program    functions 
and    user    functions,    are    useful  primarily    in   the    development 
process.       The    ether    two    measures,    lines   of    code    and   complet- 
ed   projects,    may    be    used    for    both   development    and    mainte- 
nance.     The    measures    also    hav«   relative   advantaaes    and    dis- 
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advantages    when    used    in    either   applications    or   systems 
programming    projects.       Note,    additionally,    that    there    are 
difficulties    in    maicing  comparisons    across    different    languag- 
es   or  organizations    but    here   we    are   interested   only   in    meas- 
uring the    productivity   of    the    programming    process    within 
FMSO  . 

Hence,    it    is    suggested   that   a    pilot    project    be    set    up   to 
collect    data    or.   a  number    cf  software    projects    and    that    sev- 
eral   measures    be    evaluated  using    these   data-      This    would    re- 
sult   in   two    cr   possibly    three    measures   being    selected    for 
further   testing    en   a    much    larger    sample.       After    a    reasonable 
number   of    projects   have    been    examined,    then   the    measures    may 
be    further    evaluated    tc    produce    an    operational   productivity 
measurement    system. 

5.5         IMPLEMENTATION    OF    k   HQDUCTIVITY    ^SASUREMENT    SYSTEM 

Productivity    measurement   systems,    despite    the   advantages 
discussed    above,    are    not    used    universally.       Perhaps   the    ma- 
jor   reason    for   this    is   because  these   systems    are   not    cost- 
less.     Resources    are    required,    from   both    managers    and    pro- 
grammers,   in    crder  to    implement    such   systems.       All   of    the 
measurement   systems    above    are    based    on   daily    inputs   by    indi- 
vidual  programmers  in   order  to   keep   track    of    labor   units. 
Also,    analysis    of  the   project    is    necessary   in    order   to    gen- 
erate alternative  output    measures.      However,    such    systems 
are,    in   general,    cost-effective    based   upon    their    general    us- 
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age.      in    addition  to    the    measure ment   system's  contribution 

to    the   potential    increase    in    productivity,    there    are    several 
other   reasons    that   FMSO   should  begin   to   implement    a   produc- 
tivity  measurement  system. 

The  major  reason    is  that  a   similar   system,    designed    to 
associate    specific  resources    with    specific    software   pro- 
jects,   will    be    implemented   in    the   near    future    by   DOD.       The 
Air    Force    is    the    lead    service    in    the   testing    of    the   Software 
Acquisition   Resource    Expenditure     (3ARE)    reporting   system. 
New   directives   will    require  such    reports    for    all   software 
developed    by    and    for    DOD.      Consequently,    the    forthcoming 
SARE    reporting   system    will   be    much    easier    to    implement    if    a 
data    collection    system   has   been    tested    and    is    being   utilized 
by    FMSO. 

Another    possible    reason   for    movement   to    a    productivity 
measurement    system   by    FMSO   is    to    provide    the    oasis    for    quan- 
titative   justification   of    resources   required    for   particular 
projects.      Under    the    commercial    activities    program,    ail 
no n- mission-essential   activities    are    subject    to    private    sec- 
tor   provision.       In  the   case   of   software   development   and 
maintenance,    this  program    would    require    FMSO    to    bid   on    par- 
ticular   projects    along   with  private   sector    software   houses. 
Such    bids    must    be  auditable,    which    implies    that    productivity 
information   must    be    quantitatively-based    and    verifiable.       A 
related    aspect   is  that   the  NARDAC's    are   moving    to    a   NIF 
funding    basis    instead   of    a   mission-funded    basis.       It    is   not 
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impossible   that    FMSO    and    its   customers    could    be    moved    to 
such    a  fund   accounting  basis   in    the   future . 

Although   a    produc t ivity   measurement   system   can    provide 
reasonably    precise   and   accurate    information,    it    cannot    in- 
crease  productivity    on   its  own.       Other   chapters    of    this    re- 
port   provide    other  techniques    and   methods    for    dealing    with 
productivity    enhancement    at  FMSO.      As    the    following  remark 
indicates,    these    other    factors   are    also   important. 


How    wcrksrs    feel  about   their    joos,    about    their 
fellow    workers,    about   management,    and    aoout   the 
organization,    may    be    more   important    in    influencing 
productivity  than   is    the    particular    way    they    are 
instructed   to   do    their   work,    the    formal    organiza- 
tional  structure,    or   even  financial   incentives.8 


8    This   is    found    on   page    1038    of    Nelson,    R.H.,    "Research   on 
Productivity  Growth  and    Productivity   Differences:      Dead 
Ends  and    New   Departures,"  Tha    Journal   of    Economic   Litera- 
ture,   Vol.    19,    No.     3,    September    1981,    pp.     1029-105u7 
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Chapter    6 
A    PROJECT    PLANNING    SYSTEM 

6.  1    INTRODUCTION 

Software   prelect    management    has   never    been   an   easy    task. 
The    area    is    characterized    by    slipped    schedules,    overdue    de- 


liveries   and    systems    that    do   not    work    as    they    were    in- 


ended, 


Over  the  years,  we  have  gotten  smarter  about  software  system 
development.   We  know  more  about  how  to  lo  it,  and  we  settle 
for  less  than  our  most  optimistic  hopes.   A  manager  thrown 
into  this  environment  for  the  first  time  quickly  comes  to 
appreciate  Fred  Brooks  metaphorical  use  of  the  LaBrea  Tar 
Pits  to  characterize  software  development  projects9. 

A  great  deal  has  been  written  about  software  project  man- 
agement techniques  lately.   Naturally,  most  of  the  write ups 
are  of  success  stories.   In  the  normal  manner  of  success 
stories,  they  make  the  project  management  process  seem  easi- 
er than  it  prccaoly  was.   This  is  where  the  "Grass  is  Green- 
er" syndrome  begins  to  come  in.   We  know  that  in  cur  own  or- 
ganizations, there  are  problems  that  sometimes  get  cut  of 
hand.   These  success  stories  sometimes  make  us  think  that 
everybody  else  has  things  under  control.   The  answer  then 
seems  to  be  to  take  the  methods  that  have  (presumably) 


9  Fred  Brooks,  The  Mythical  Man- month ,  p.  3. 
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worked   vail   elsewhere   and   adapt,    them   to   oar   organizations. 

This    would    te    a   great    idea    if    it    wer=    possible,    but    un- 
fortunately,   there  are  a    few    hitches   in   the    process.       Soft- 
ware   projects   are  not  simple,    and   they    are   not    standardized 
across  organizations.      The  standards  for   measuring   produc- 
tivity in    different    organizations   are   going   to    be    vastly 
different.      We   can  learn   a   lot   about  installing   a    project 
planning    and   control    system  by   observing   the   techniques    that 
have    worked   elsewhere,    but  we    have    to    be   careful.      It    is    es- 
pecially   dangerous   to  take  productivity   figures    from    one    or- 
ganization  as   necessarily   being    indicative    of    what    we    can 
expect.       First    of  all,    we    have  to    know    what    they   think    pro- 
ductivity   is    and    how    they   account    for    it.       That    information 
rarely  appears   in   the   articles    in   sufficient    derail  to    allow 
us    to   reconstruct  the   measures   used   by    the   original  re- 
searchers,   much    less    use    them    in    our   own    organizations. 

What    we    will    have    to    do   is    to    develop    our    own    models 
(probably    patterned    on  these   developed   elsewhere),    gather 
data    on    how   they    work,    and   gradually    develop    our   own    system 
for    project   estimating.       This    implies    that    a    project   estima- 
tion   model    has   to  be    tailcr  made    for   a    given    organization. 
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6.2         PROJECT    PLANNING    AND   CONTROL    SYST3HS 

Just    because    project    plar.ni.ig    and   control    systems    must    be 
tailored    to    a    giver,    organization,    this    ices   net    mean    that 
there   is    net    considerable    guidance    available    on    successful 
approaches   to    project    planning   systems.      There    are   two    major 
approaches    we    would    recommend   considering    as    models    for    a 
project    planning    system    at   FMSO.       The    first    cf    these    is    the 
SLIM    system   developed    by    Lawrence    Futnam10.       Putnam's    model 
is    based    on   the    Rayleigh    Curve   and    can    be    used    to    estimate 
effort   required   and    timing   of   effort    for    medium   to    large 
scale   software   projects.       The    SLIM    model    is    available    over 
time    sharing    services   and    could    serve    as    a    useful    first    ap- 
proach to    developing    local   project    planning    models   at    FMSO. 
A    good  source    for   information   on    the    SLIM    model    and   the    way 
in    which    it   is   used    for    project    planning    is   given    by    Vor- 
gang11.      The    SLIM  model    is   basically   a   macro   approach    to 
cost    and    effort    estimation   that    makes    reasonable    assumptions 
about   the    type   of  work   being   done.      It   seems    to    offer    a    lit- 
tle   less    flexibility    than    you    would    get   by    developing    your 
own    model,    but   it  is    probably    a    gocd   place    to    start   investi- 
gating the   subject. 


10  A    detailed   account    of    Putnam'  s   model   is    found   in   Lawrence 
Putnam,    "A   General   Empirical    Solution    to   the   Macro    Soft- 
ware   Sizing   and  Estimating    Problem",    IEEE    Transactions   on 
Software    Engineer inq ,    July    1978,    pp.    34  5    -    36  1. 

11  Blair    Roland    Vorgang,    "A   Macro    Approach    to   Software    Re- 
source   Estimation    and    Life   Cycle   Control",    Master's    The- 
sis in    Computer  Systems  Management,    Naval    Postgraduate 
School,    December    1981. 
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The  next    project    planning   model    is    the    COCOMO    (for 
constructive    COst  MO del)     system    developed    by    Barry   Boehm12 
of    TEW.       Bcehm    provides    a    detailed    description   of    the    COCOMO 
system   in    his    bock.       The    data    used    to    derive    the   model    comes 
from   experience    in  software  development  at    TRW.      Unfortu- 
nately,   this   experience    may  not    be    entirely   relevant    to 
FMSO's  software    development  situation.      There   is  not    a    suf- 
ficient   number   of  COBOL    data    points    used    to   derive   the    pa- 
rameters   of   the    model.      The  COCOMO    model    probably    works    bet- 
ter   in   the    scientific   computing    environment   common    in    the 
aerospace    industry  than    it   does    in    a   purely    data   processing 
environment. 

However,    Bcehrrt   is    detailed   enough    about    how    the   models 
are    put    together   that   he    provides  an   excellent    pattern    to 
follow  in    developing    your    own   project    planning    systems.       The 
COCOMO   system    is    divided    into    basic   and   intermediate    models. 
Both    systems    are    used   to    predict    the   effort    required   to    de- 
velop a    software   product.    The    basic   system    uses   a    single 
predictor    variable,    number   of    lines   of   source   cods   required, 
and    three    different    modes    of   development.       The   three    modes 
are: 

Organic   Mcde  -    In  organic  mode,    relatively    small 
software  teams    develop    software    in    a    highly 
familiar, in-house  environment.       Most    people 
connected    with    the   project    have    extensive  ex- 
perience in   working    with    related    systems 


12    The  COCOMO    model    as    well  as   a    number   of    other   important 
issues    in    project    planning   and  cost   estimation    are    de- 
scribed  in   Earry    Boehm,   Software   Engineering    Economics, 
published   by    Prent ice- Hall ,    Inc.,    1981. 
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within    the    organization,    and   have   a    thorough 
understanding    of   how   the    system    under    devel- 
opment   will    contributed   to   the   organization's 
objectives. 


Embedded    Mode   -    In    embedded    mode,    the   distinguish- 
ing   factor    of    a    project   is   a    need   to    operate 
within    tight    constraints.      The    product    must 
operate   within    (is   embedded    in)     a    strongly 
coupled  complex    of    hardware,    software,    regu- 
lations and  operational   procedures,    such   as 
an    electronic    funds   transfer   system   or    an   air 
traffic  control    system. 


Semidetached  Mode   -    The    semidetached    mode    is    an 
intermediate    level    between    the    organic   and 
embedded   modes.      The   project   contains    mix- 
tures  of   both    embedded    and   organic    mode   char- 
acteristics . 


FSMO's   mode   of    project    developed ent    could    normally    be    char- 
acterized   as    organic    mode,    although    some    of   the    projects    un- 
dertaken   by    the    Environmental   Group    would    probably    be    con- 
sidered   to    be    embedded   mode. 

At   this    basic    level,    Bcehm    reports    that    CCCOMO    pre- 
dictions   come    within    a    factor   of    1.3    of   actuals    29%  of    the 
time    and    within    2.3    of   actuals   6  0%   of    the    time.       If   these 
results    do   not    seem    overly   impressive    yoa    can    move    to    what 
Boehm  calls    intermediate    CCCOttC.       In   this    enhancement    of    th- 
model,    Boehm   adds  an    additional    fifteen   factors    or    "cost 
driver  attributes"  that    are  given   below.       The   names  of    the 
variables    are    those    used    in   Bohem's    model    itself. 

Froduct    Attributes 

RELY   -   reguired    software    reliability 
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DATA    -    data    base    size 
CPLX    -    product  complexity 

Computer    Attributes 

TIME    -   execution    time   constraint 
STCR    -   main    storage  constraint 
VIRT    -    virtual   machine   volatility 
TUBN    -   computer    turnaround   time 

Personnel  Attributes 

ACAP    -   analyst   capability 
AEXP    -    applications  experience 
PCA?    -   programmer    capability 
VEXP    -    virtual   machine   experience 
LEXP    -   programming  language   experience 

Project    Attributes 

MOEP   -   modern   programming   practices 

TOOL    -    use   of  software  tools 

SCED    -   required    development    schedule 

Each    of    these    parameters    are   assigned    weights    (called    "ef- 
fort   multipliers"   by    Boehm),    and    these   weights    are   used    mul- 
tiplicativly  to    adjust   parameters   in   the   model.      Boehm 
claims  that    with    intermediate    COCOMO,    he   is    within    20%    of 
actuals    685?   of   the  time. 
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In   many    ways,    the    type    cf    data   collected    by    Boehm    for    in- 
termediate  COCCMO   is    similar    to    that   already    considered    by 
PMSO    for    its    own    project    estimation    data   gathering.      This    is 
not    surprising   since    Boehm's    model    passes    what    could    be 
called   a    "reasonable    man"    test.       The   parameters    in    the    model 
are    those    that    an  experienced    professional    would    probably 
expect   to    find   contributing  to   effort   required    in    a   software 
development    project.       With   Boehm's    model,    or    any    software 
development    model,    one    must   be   careful    how    it    is    applied. 
The    development    cf   such    an  estimation    model    is    an    evolution- 
ary   process   and    there   are    many    opportunities    for    problems. 
Putnam   cautions    that    "I    have    found    that    manpower    data    accu- 
mulated   to    a. yearly    value    is   not    mere    accurate    than   +/- 
10-15%   of    the    reported    value.      If    the    data    are    examined    at 
shorter    intervals,   the   percentage    variation   tends   to    be   eve- 
greater"13.      It    will    take    time   to    figure    out    what    the    bias 
caused    by    accounting    problems    is    in    your    organization    and 
how    these    should    be    accounted    for    in    the    model.       In   addi- 
tion,   -here    is    probably    a    "Hawthorne    Effect"    present    in 
software    management.       As    a   model    is   developed,    the   tighter 
controls    are    likely    to    bring   about    increased    programmer 
awareness    cf    management    goals.       To   a    certain    extent,    the    ef- 
fort   projections    may    become  self    fulfilling    prophecies. 
They    determine   the  time    alloted    to    the   software    project,    and 


13    Lawrence    Putnam,     "A   General   Empirical    Solution    to    the 
Macro    Software  Sizing    and   Estimating   Problem",    IEEE 
Transactions   on    Software   Engineering,    July    1973,    p    3U6 
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at    the   end    of    that   rims,    the   project    is   declared   done    unless 
it    has  truly    major  deficiencies. 

Whatever    model  is    used    for    projections    in    the    FMSO    envi- 
ronment,   it   should   be    kept   in    mind    that   software   effort    es- 
timation   is   net    an  exact    science    by   any   means.      The   models 
will    have    to    be    developed    in    an    evolutionary    fashion    and 
will    have    tc   be    geared  to   FMSO's    unique   situation.      More- 
over,   as    technology    changes    (assuming,    for    example,    that    the 
recommendation    to  acquire    a   development   tools    machine    is 
taken),    then    it    is  to   oe    expected   that    it    will    be   necessary 
to    change    the    models    used    as    well.       It    will    probably    take   a 
number  of    years   to  come    up  with    a   useful   model. 

6»3         CONCLUSIONS 

FMSO    should   begin    some    preliminary    work    on    developing    a 
project    planning   and    effort  estimation   model.      Some  of    the 
work    has    already    been   done  in    that    there    has    been    data    gath- 
ering done    on    the  time   required    for    projects,    and  the    forms 
used    are    similar   to    those    in    use    elsewhere.      The    next    step 
will    be   tc    analyze  the   data  collected,    to    begin    tc    develop 
some    computer   models    of    effort    and    then   attempt    to    validate 
these   models    en   on-going    FMSO   scftware    development    projects. 
This    wcrk    need   not   wait    until    the   acquisition    of   a    develop- 
ment   tools   system.      It  could    probably   be    initiated   using   any 
of   the   micros    currently    in  place    at   FMSO. 
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